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ABSTRACT 

Meeting bandwidth demand successfully is one of the important issue for multimedia application. In this paper I 
propose a protocol of AODV routing protocol named as ICBCC-AODV (Integration of current bandwidth capacity 
calculation) protocol which calculates current bandwidth compares with required bandwidth and then forwards data to 
destination. 
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L INTRODUCTION 

Many routing protocols have been proposed in ad hoc networks, and these can be classified into two categories: 
table-driven (proactive) protocols and on-demand (reactive) protocols. Reactive protocols: create and maintain routes only 
when they are desired, and differ on how they discover and maintain routes between sources and destinations. 
Proactive protocols: require each node to maintain one or more tables to store routing information from each node to all 
other nodes in the network, regardless of whether they are actually used or not. In this article we are interested by Ad hoc 
On-demand Distance Vector (AODV) Routing protocol [2]. AODV is a distance vector routing protocol. AODV is an pure 
on demand routing protocol, so that a route is only discovered when required by a source node. A node does not need to 
keep routing or reserve bandwidth that does not need. AODV eliminates periodic routing updates and propagate if nodes 
bandwidth capacity is satisfied by the nodes required bandwidth to be send to the destination. A majority of ad hoc 
applications involve voice communications while some may require video transmissions. Thus Quality of Service (QoS) is 
desired to provide the required service differentiation to the demanding connections. However providing QoS assurance in 
MANETs is a very complex problem due to the characteristics of the network, such as the mobile nature of the nodes 
resulting in an unpredictable topology, scarce wireless bandwidth which varies with the changing environmental 
conditions, limited mobile device power and the requirement of node cooperation to relay packets through the network. 
In this paper we propose and implement an enhanced version of AODV, using the Network Simulator 2 (NS2)The main 
objectives of this work is to propose a QoS aware AODV routing protocol based on the draft "Quality of Service for Ad 
hoc On-Demand Distance Vector Routing" [1], to implement (using C++ programming language) this by amending the 
source code of the existing AODV routing protocol employed within NS2 and analyse (using TCL(Tool Command 
Language), AWK (Aho Weinberger Kaho)) the effects of these changes and, comparing the ICBCC_AODV network 
performance measures (i.e traffic delay, bandwidth) with the unchanged AODV protocol. In the section II, we present 
some QoS works in the ad hoc networks. Section III describes the problem definition and the network model. 
Our admission control is described in section IV, the oS_AODV route establishment is explained in section V, in section 
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VI we propose a mechanism to calculate the CBC for a given node. Simulation results and a comparative study are 
presented in section VII, the last section conclude our paper. 

II. LITERATURE 

In the literature, the research on QoS support in MANETs spans over all the layers in the network [4]: 

• QoS models specify an architecture in which some kinds of services could be provided. 

• QoS Adaptation hides all environment-related features from awareness of the multimedia-application above and 
provides an interface for applications to interact with QoS control. 

• QoS routing is part of the network layer and searches for a path with enough resources but does not reserve 
resources. 

• QoS MAC protocols are essential components in QoS for MANETs. QoS supporting components at upper layers, 
such as QoS signaling or QoS routing assume the existence of a MAC protocol, which solves the problems of 
medium contention, supports reliable communication, and provides resource reservation 

Existant Approaches 

• SWAN [5] is a QoS provisioning system that treats UDP traffic as real time and TCP traffic as best effort. It uses 
admission control based only on bandwidth measured along the path of communication by sending a probe 
message. 

• The QPART protocol [8] is based on a passive estimation of bandwidth and a dynamic regulation mechanism of 
best effort flows. 

• In [10] the authors propose an improved mechanism to estimate the available bandwidth in IEEE 802.11-based ad 
hoc networks. They have integrated this bandwidth evaluation technique (ABE) into AODV protocol and 
implemented it under NS-2. This protocol is called ABE-AODV. 

III. PROPOSED AODV ROUTING PROTOCOLNAMED AS ICBCC-AODV (INTEGRATION OF 
CURRENT BANDWIDTH CAPACITY CALCULATION) 

The decision of whether to accept or reject a flow is done by admission control procedure based on resource 
availability basis. In reactive routing protocol AODV, when a node wants to communicate to another node and does not 
know a route to the destination, it sends out a route request (RREQ) message 

I extend this RREQ message to include the quality of the wanted route to destination in terms of ICBCC 
parameters like maximum end-to-end delay, minimum bandwidth (MB). 

I Denote 

ICBCC_AODV_RREP = RREP U {MB, D} 

Where D is the required maximum end-to-end delay, MB is the minimum bandwidth that the application will 
require, RREQ is the RREQ packet of original AODV, RREP is the RREP packet of original AODV. So the route to the 
destination must have available bandwidth greater than or equal to MB. In our protocol the source node's network layer 
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gets a request in the format of ICBCC_AODV_RREQ (figure 1), from its application. It removes D from 
ICBCC_AODV_RREQ, stores D locally, starts a timer with value 2*D, and sends out the route request RREQ with the 
remaining parameters. When an intermediate node gets this ICBCC_AODV_RREQ, it uses MB to determine whether to 
forward the route request or drop it. An intermediate node compares the requested minimum bandwidth (MB) with its 
current bandwidth capacity (CBC). If the node's CBC is higher, the node rebroadcasts the route request to its neighbours. 
If the CBC is less than MB, the node drops the route request. By this way if the ICBCC_AODV_RREQ reaches the 
destination by satisfying the bandwidth constraint then the destination records the MB contained in the 
ICBCC_AODV_RREQ and replies with a ICBCC_AODV_RREP To include the user defined quality of service 
parameters (minimum bandwidth (MB) the AODV RREQ packet is modified. The RESERVED field within the normal 
AODV RREQ packet is used to carry the information during the route establishing process. This extended version of the 
AODV RREQ will be referred as ICBCC_AODV RREQ (figure 1). The RESERVED field has total length of 16 bits, 
the maximum value that can be passed in a ICBCC_AODV RREQ packet is 65536 (216). 

IV. ICBCC_AODV ROUTE ESTABLISHMENT 

To describe how the ICBCC_AODV works, consider a scenario in which a node , S wishes to communicate with 
another node, D. if node S has no valid path(s) to D in its routing table, then a route request is initiated. Node S broadcasts 
the extended AODV RREQ packet to its neighbours. Upon receiving these RREQ packets, the intermediate nodes 
(nl, n2,...,nj) compare the RREQ_ICBCC_BANDWITH field value, within the RREQ packet, say, x kbps with their 
Current Bandwidth Capacity, CBC kbps. If these intermediate nodes are already engaged in other traffic sessions then their 
total available bandwidth capacity will vary. The nodes which cannot accommodate the user-specified minimum 
bandwidth, x kbps, the 'busy' nodes, will not discard the ICBCC_AODV_RREQ initially it will forward 
ICBCC_AODV_RREQ to the successor if not satisfied there it forward to predessor if not satisfied there also it will be 
discarded. The nodes which do satisfy the bandwidth requirement, broadcast the ICBCC_AODV_RREQ to their 
neighbours. A reverse route entry is added in the routing table of the ICBCC_valid node that unicasts the 
ICBCC_AODV_RREQ packet. This process continues until a node receives the ICBCC_AODV_RREQ and has a fresh 
enough route to the destination node, D in its routing table, or itself is the destination node: 

V. DYNAMIC CURRENT BANDWIDTH CAPACITY (CBC) CALCULATION 

Below we propose a mechanism to calculate the CBC for a given node which will be implemented and 
incorporated within the AODV routing protocol in NS2.The proposed method to monitor and update a nodes traffic status 
in based upon session flows. This will include keeping track of the various flow statistics over a period of time. 
The instance at which a traffic flow session is started at any given node, the start-time for every unique flow session is 
stored. As the data packets arrive and are processed by the nodes, other information necessary for the CBC calculation is 
extracted from the IP data packets such as: packet size, flow id, source node, destination node, etc. For each individual 
session flowing through a node, the total number of bytes (calculated from the data packet size for each different flow) 
sent/forwarded by the node is monitored .The start-time for each flow is used to work out the interval between packets 
which are part of the same flow. The CBC is calculated and updated constantly and is a new addition to the nodes routing 
table. 

Formula used to calculate bandwidth is: 
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CBC[j]=8*sum[j]/((end_time-start_time)/1000) 
Where: 

j: flow number 

sum[j]: sum of all flow j packet size in byte. 
CBC[j]: current bandwidth capacity of flow j. 

Below are the flowcharts of the RREP and RREQ which shows whole working of the proposed algorithm. 
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Figure 1: Flowchart for RREP in IBCC-AODV 

Evaluating ICBCC_AODV performance metrics to analyze the effectiveness of the proposed and implemented 
ICBCC_AODV routing protocol, the simulation scenario described above is carried out with the normal AODV protocol 
and the extended ICBCC_AODV one. Network performance metrics will be used to compare the results, are the 
end-to-end delay of the traffic flow/session, packet delivery ratio. [packet_Time (destination)-Packet_Time (source)], 
and the node bandwidth processing performance: as the ultimate valid path chosen by ICBCC_AODV that satisfies the 
quality of service defined, depends on the status of each node, analyzing the CBC values for all nodes involved can will 
verify the routing decision undertaken by the ICBCC_AODV routing protocol. 
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Figure 2: Flowchart for RREQ of IBCC- AODV 



VI. SIMULATION 



Table 1: Simulation Parameters 



Parameter 


Value 


Topology Size 


500x500 


Simulation time 


200s 


Number of Nodes 


10 20 30 40 50 60 70 


Different traffic sources 


2 


Traffic flow 1 


Normal AODV 


Traffic flow 2 


AODV_IDBCC 



The Minimum bandwidth (MB), delay is assumed here according to the readings of normal AODV. 
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VII. RESULTS 



Table 2: Pdr Readings 



No of 
Nodes 


Simple 
AODV 


AODVJCBCC 


10 


0.999555 


0.999514 


20 


0.999494 


0.999453 


30 


0.999534 




40 


0.999656 
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0.999514 
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0.999534 
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0.999656 
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Figure 3: Pdr Graph 
Table 3: End to End Delay Readings 



No of 
Nodes 


Simple 
AODV 


AODVJCBCC 


10 


0.004391 


0.062092 


20 


0.004337 


0.062903 


30 


0.004429 


0.204202 


40 


0.004446 


0.181172 


50 


0.00469 


0.163382 


60 


0.004444 


0.155748 


70 


0.004476 


0.154373 



0.25 
0.2 

0.15 
0.1 

0.05 
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Figure 4: End to End Delay Graph 

From the graph we came to conclusion that our pdr increases as number of nodes increases and the end to end 
delay also increase as number of nodes increases. 
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VII. CONCLUSIONS 

In this paper, an enhanced version of AODV routing protocol was proposed. We have implemented our admission 
control mechanism using the Network Simulator 2 (NS2) Where the source node checks the end-to-end delay and all the 
intermediate nodes perform bandwidth check. Our algorithm is based on the modification of the AODV RREQ and AODV 
RREP packets, to include the user defined quality of service parameters (minimum bandwidth (BP) and maximum 
delay(D)); it also compute the Current Bandwidth Capacity (CBC) for a given node which will be implemented and 
incorporated within the AODV in NS2. We have developed some components of the network Simulator NS 2 to adapt our 
algorithm. It is seen from the simulation results that our proposal ICBCC_AODV gives a very good packet delivery ratio 
which secures packet from getting dropped thus enhances the node bandwidth processing performance. In future work, 
we envisage to improve our current ICBCC_AODV proposal by making it compared with others protocols, and making 
end to end delay better for data to be transferred. 
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